Why I added a Lync Director Pool (also if I don’t like it)

Intro and Scenario

Recently I have been working on a migration scenario (from Lync 2010 to Lync 2013). It has been interesting, and I will write about some hints and tricks I have used in the next days.

The existing deployment included a Lync 2010 Enterprise Pool on the central site and a remote site with a Lync 2010 Standard Edition server (and a third site with a SBA).

As it was required in Lync 2010 there was also a Lync Director Pool to manage the access on different pools (the Internet connection is available only on the central site, external users from all the sites accessed to their home server through the central site).

Anyway, one of the requirements was not to use Lync 2013 Enterprise Edition pools, so my first idea was simply to put a pair of Lync Standard Edition servers on the central site and pair them for resiliency. Another idea I had was to remove the Director Pool because Lync 2013 Front Ends are able to redirect users to their home server

The base reason to have a Director was no longer present.

I replaced the Lync 2010 Edge pool with a Lync 2013 Edge pool and pointed it and the reverse proxy to one of the Lync 2013 Front Ends.

It works, external users homed on the various Front Ends connect to the central site and then are redirected to their home server.

The schema is the one you see in the image, and if you look at it with a keen eye, you already know why it has a really big weak point.

Here Comes the Director Pool (Again)

If one of the Front Ends goes down and is not recoverable in a short time, we can use the Front End pairing.

But if the wrong Front End one goes down, all external users will be unable to log into Lync (also after we have moved the users homed on the failed server).

That is because we have a connection from Edges and reverse proxy that points to a single Front End.

My only solution was to add a Lync 2013 Director Pool to the topology and make it next hop for the Edge Pool and for the reverse proxy (probably a scenario with a load balancer would have been different).

To Conclude: Why I Do Not Like the Lync Director

1. It’s the Lync role with the worst documentation
2. Following the Murphy’s laws, as soon as I added the Lync 2013 Director, I had a weird problem with the users homed on Lync 2010
3. Few people have deployed Lync 2013 Directors (because usually you don’t need them) so there was also few first hand experiences on the topic